Many validation, quality control/quality assurance, and other multi-user testing processes involve more than one party that depends at least in part on a test result of a work product provided by yet another party. For example, electrical devices are frequently delivered only upon successful completion of test on the electrical infrastructure at a building site. In another example, and especially where a previous test was not successfully completed, changes to an already existing structure may need to be implemented by an engineering team, and such changes will further have to be relayed to other parties involved in the construction.
Typically, validations or tests are performed in a sequential manner in which a user tests a structure, process, or other component, and then relays the test result to a central record keeping organization (e.g., engineering firm, clinical trials coordinator; US2004/0025030). Where the test sites are in a remote location relative to the organization, such validations are often performed by a user at the test site using a portable data entry device (e.g., laptop computer, PDA, or notebook), and the results are then entered into a central computer once the user returns to the organization. Such process is not only time consuming, but may also be error-prone where complex and/or numerous structures or parameters are entered. Even if data entry is automated, such processes are generally limited to those in which the validation request remains unchanged over a plurality of tests. Furthermore, where a second party requires a specific test result for further progress (e.g., determination of a modified distance between two points in a structure, or availability of infrastructure), that test result may not be available to the user for several hours, and more typically even days.
In other acceptance test procedures, tests are performed and results recorded in writing, for example, with sequenced steps being initialed as performed. At times, witness signatures are required as well, for example, where a critical system or subsystem is being tested. If errors arise, then separate exception reports are filled out documenting the cause of the error and/or exception so as to document the actions required to remedy and then retest. To alleviate at least some of the burden in such processes, computer checklists are employed that specify the test sequence and validation steps. However, such checklists are usually in form of a word processing document that is filled out on a laptop or pocket PC.
Thus, while there numerous manners of testing and validation are known in the art, all or almost all of them suffer from one or more disadvantages. Therefore, there is still a need to provide improved systems and methods for integrated acceptance testing.